Configuring a computer system to perform specific functions (for example, electronic commerce, web services, business transaction processing, electronic data communications, etc.) often includes the integration of disparate hardware and software from various sources. A particular component for such a system may be configured for operation with one or more other components in accordance with a first protocol. However, a systems integrator may wish to have the particular component operate with a specific other component that does not support that first protocol
For example, it is often desired to integrate a data store component comprising a directory or other database with another component of a system. Data stores are typically defined in accordance with specific schemas and protocols for accessing information in the data store. One such protocol is the Structured Query Language (SQL) for accessing relational database management system (RDBMS) databases and another is Lightweight Directory Access Protocol (LDAP) for providing access to directory services, specifically, X.500-based directory services optimized for reading, searching and browsing information. Each has particular advantages or other characteristics which may make its use desirable in a computer system. For example, LDAP is adapted as a network protocol for accessing information in a directory and can be easy to implement in a client component for accessing information stored remotely. It is often used for email clients to access directory information (e.g. an address book). SQL-based databases are available widely from different vendors and provide complex functionality including transactional support and roll-back schemes not typically found with LDAP directories.
Sometimes a data store in a computer system is to be shared by multiple components that are configured for different protocols. Thus there are times when a component and a data store are incompatible, for example, with the data store configured for SQL operation and the component configured for LDAP operation.
One implementation of LDAP is OpenLDAP, an open source community developed software data store coordinated by the OpenLDAP Foundation. One component of this software is a LDAP server for providing LDAP access to data stored in one or more backends. OpenLDAP provides access to various backends or storage types (i.e. types of databases) through specific modules. OpenLDAP is configured to provide backends of three general categories, namely those that 1) store data, 2) proxy otherwise stored data or 3) generate data on the fly. One proxy backend is back-sq1 for mapping an SQLbased RDBMS to a directory service agent (DSA). Examples of supported RDBMSes are DB2 from IBM, MySQL from MYSQL AB and PostgreSQL from PostgreSQL Global Development Group.
However, as back-sq1 proxies an SQL-database for multiple purposes and the schema is predefined by the needs of OpenLDAP, it performs more work than may be necessary and incurs more overhead (storage and other resources) than may be desired such that its performance characteristics are not suitable. Black-sq1 is configured to use its own proprietary database schema rather than an external database schema even if an existing SQL database is defined in accordance with its respective database schema.
Accordingly, there is a need for a simple LDAP to SQL database proxy.
For convenience, like numerals in the description refer to like structures in the drawings.